As shown in FIG. 1, the existing service processing system includes: a PCRF entity, adapted to decide Policy and Charging Control (PCC) rules according to the network access restrictions imposed on a user, service provider policies, and subscription data obtained from a Subscription Profile Repository (SPR), and user's underway service information obtained from an Application Function (AF) entity, and provide the PCC rules for a Policy and Charging Enforcement Function (PCEF) entity, whereupon the PCEF entity executes the PCC rules that include a service data stream detection rule, an access control rule, Quality of Service (QoS) corresponding to the service data stream, and a stream-based charging rule; a PCEF entity, set in a gateway and adapted to detect the service data stream according to the PCC rules delivered by the PCRF entity, execute the policies (including QoS policies) to ensure the QoS of the service data stream, and perform stream-based charging; a SPR, adapted to store subscription data; and an AF entity, adapted to provide service-layer service information for the PCRF dynamically so that the PCRF generates or modifies the corresponding rules dynamically according to the information.
Based on the foregoing communication system, the process of setting up an Internet Protocol Connectivity Access Network (IP-CAN) session and the process of setting up an IP-CAN bearer are described below by reference to FIG. 2 and FIG. 3.
As shown in FIG. 2, the process of setting up an IP-CAN session includes the following steps:
Step 201: After receiving an IP-CAN session setup request from a user terminal, the PCEF allocates an IP address visible to a Public Data Network (PDN), and sets up the first PDP context.
Step 202: The PCEF creates a new Diameter Credit-Control (DCC) session, and sends a Credit-Control-Request (CCR) message which notifies the PCRF to set up an IP-CAN session. The CCR message carries a user terminal identifier and an IP address.
Step 203: The PCRF stores the user terminal identifier and the IP address carried in the CCR message.
Step 204: The PCRF sends a subscription profile request to the SPR when requiring the subscription-related information.
Step 205: The SPR returns a subscription response which carries the information such as the service currently subscribed to by the user, and the charging mode.
Step 206: The PCRF generates a new PCC rule.
Step 207: The PCRF stores the PCC rule.
Step 208: Through a Credit Control Answer (CCA) message, the PCRF returns the PCC rule to the PCEF.
Step 209: The PCEF loads the rule, and connects or disconnects the corresponding service data stream according to the rule in order to ensure the corresponding QoS.
Step 210: The PCEF returns an IP-CAN session setup response to the user terminal.
As shown in FIG. 3, the process of setting up an IP-CAN bearer includes the following steps:
Step 301: After receiving a trigger event (for example, a multimedia call control signaling initiated by the user terminal to start an AF session), the AF entity needs to set up a new Diameter session and provide service information for the PCRF.
Step 302: The AF entity extracts the desired service information (for example, IP stream address information, port ID, and media type) from the trigger event.
Step 303: The AF sends to the PCRF a Diameter Authentication Authorization Request (AAR) message which carries service information.
Step 304: The PCRF stores the received service information.
Step 305: If the PCRF has no subscription profile of the user at this time, the PCRF sends a subscription request to the SPR to obtain the subscription profile of the user.
Step 306: The SPR responds to the PCRF with a subscription response which carries information about the service currently subscribed to by the user.
Step 307: According to the received service information and the information from the PCEF (for example, IP address of the IP-CAN session), the PCRF correlates the AF session with a corresponding IP-CAN session.
Step 308: The PCRF returns an Authentication Authorization Answer (AAA) message to the AF entity. The AF entity sends the AAA message to the user terminal. After receiving the AAA message, the user terminal sends an IP-CAN session message to the PCEF.
Step 309: After receiving the IP-CAN session message from the user terminal, the PCEF requires setup of a new IP-CAN bearer, and sets up the second PDP context.
Step 310: The PCEF sends to the PCRF a CCR message which notifies the PCRF to modify the IP-CAN session and requests for the PCC rule for the IP-CAN bearer.
Step 311: The PCRF stores the IP-CAN bearer information carried in the CCR message.
Step 312: The PCRF uses the information received from the PCEF and the service information to correlate the IP-CAN session with a specific AF session (one IP-CAN session may be correlated with multiple AF sessions).
Step 313: The PCRF generates a new PCC rule according to the information such as service information, subscription profile of the user, and service provider configuration.
Step 314: The PCRF stores the new PCC rule.
Step 315: The PCRF responds to the PCEF with a CCA message which carries the new PCC rule.
Step 316: The PCEF loads the rule, and connects or disconnects the corresponding service data stream according to the rule in order to ensure the corresponding QoS.
Step 317: The PCEF returns an IP-CAN session response to the user terminal, thus finishing the setup of the IP-CAN bearer.
Through the foregoing IP-CAN session setup process and IP-CAN bearer setup process, a binding relation between the IP-CAN session, the IP-CAN bearer and the PCC rule is generated on the PCEF entity, as shown in FIG. 4. For example, the user terminal succeeds in setting up an IP-CAN session once an addressable IP address is allocated to the user terminal. In the process of setting up the IP-CAN bearer, the PCC rule transmitted by the PCRF through the Gx interface to the PCEF includes the QoS control parameters: bandwidth and QoS level identifier of the service data stream. In order to meet different QoS requirements, IP-CAN bearers compliant with different QoS requirements may be set up in the same IP-CAN session. For example, the service that requires a high QoS level (for example, a Voice over Internet Protocol (VoIP) service, and a multimedia call) may be carried on IP-CAN bearer 1; and the service that requires a low QoS level (for example, file downloading, web page browse) may be carried on IP-CAN bearer 2. Each IP-CAN bearer may bear multiple IP streams (for example, the user may download files on different servers simultaneously). The PCEF may identify the IP stream according to the PCC rule (the PCC rule includes an IP quintuplet, namely, IP source address, IP destination address, IP source port ID, IP destination port ID, and protocol), and may put IP streams into different IP-CAN bearers according to the QoS required by the PCC rule. Each PCC rule may correspond to one or more IP streams (also called service data streams).
In the mechanism provided by the existing PCC, the PCRF decides the QoS parameters such as QoS level identifier and bandwidth of the service data stream according to the policy context information (for example, priority of the application service, priority subscribed to by the user, custom-defined QoS policy configured by the service provider), and then transmits the IP quintuplet filter rule of the service data stream and the corresponding QoS parameter to the PCEF through the Gx interface. The PCEF exercises QoS control for the service data stream according to the QoS parameter of the service data stream, and ensures the corresponding QoS levels for the service data streams that require different QoS levels.
In some scenarios, when service data streams require the same QoS level, the bearer layer needs to distinguish between the service data streams. For example, for different voice services, an ordinary voice service and an emergent voice service, their QoS requirements such as bandwidth, transmission delay and packet loss ratio are the same, but the emergent voice service is expected to be fulfilled first when the two services contend for the same bearer transmission resource. In an example, if different users require the same QoS level, the different users need to be distinguished according to the subscribed user type, and the user of higher priority (such as gold user) is expected to be satisfied first when different users contend for the same bearer transmission resource. In the existing PCC mechanism, the PCRF can only export the bearer-layer QoS level identifier and transmit it to the PCEF for undergoing QoS control. It is not possible for the PCEF to handle the bearers requiring the same QoS level discriminatively according to different conditions.
In the prior art, a concept of Allocation/Retention Priority (ARP) is put forward. The allocation priority is used for allocating resources according to the priority when the user sets up a Radio Access Bearer (RAB), and the retention priority is used for a Universal Terrestrial Radio Access Network (UTRAN) to retain resources according to the priority after the service is set up. However, the ARP does not reflect priority of a specific service, and a possible sequence is: The service of higher priority has a low ARP level, and therefore, the corresponding user session is released. That makes it impossible to reserve resources of the access network based on service priority, and makes it impossible to support the service priority throughout the network.
To sum up, the prior art does not allow for the factor of the policy context and cannot handle services discriminatively according to the policy context when different services require the same QoS level.